Size Change: +484 B (0%)

Total Size: 1.26 MB

_{compressed-size-action}

@getdave good point on the RTL, I pushed a fix for that, using margin-inline-start!

I just tested a bit and this breaks the layout if we have more blocks... I rushed to 🟢 😄

Good catch thanks @ntsekouras. I added a margin-inline-end: auto to the previous link so now it works like this:

Thanks Ben! This seems to work well with the basic 'expected' scenarios:

1. previous + numbers + next
2. previous + next

If we change that order it might break some layouts.. I'll leave the decision to you as a theme dev and we can possibly keep an eye to it..

Another thing I was thinking is if we should restrict somehow Query Pagination to only allow these blocks and only once at most.. Do you think there are cases we need something more?

A final thing would be unrelated to this PR about layout, but is visible here. If we have space-between and change orientation to vertical the space-between css class is not reset as it should, because it's not available in the vertical orientation. This normally doesn't affect something, but here with specific css rules, it does. --cc @aaronrobertshaw @andrewserong

Another thing I was thinking is if we should restrict somehow Query Pagination to only allow these blocks and only once at most.. Do you think there are cases we need something more?

I think the block is already limited to only allow these blocks as inner blocks.

I think the block is already limited to only allow these blocks as inner blocks.

You're right, yes!

If we change that order it might break some layouts..

Good point, I've added a commit to restrict this CSS to only apply when the next/previous links are last/first elements.

There is an open issue for restricting the number of times the inner blocks can be added: 42580

A final thing would be unrelated to this PR about layout, but is visible here. If we have space-between and change orientation to vertical the space-between css class is not reset as it should, because it's not available in the vertical orientation. This normally doesn't affect something, but here with specific css rules, it does. --cc @aaronrobertshaw @andrewserong

Oh, thanks for the ping here @ntsekouras — currently the logic that outputs the semantic classnames in layout.php is quite simple and just looks at the presence of particular attributes. One of the tasks in the Layout tracking issue is to explore how we can centralise output of styles associated with the classnames, so I think it'd be good for us to look at the conditions for each attribute as part of that work. That's not a quick fix, though, but I've got it on my todo list to explore, if no-one beats me to it. I'll add a link to this discussion so that we keep this particular case in mind (perhaps an allow-list of values based on orientation?).